In the field of computer networking, a visibility network (also known as a “visibility fabric”) is a type of network that facilitates the monitoring and analysis of traffic flowing through another, “core” network (e.g., a production network). The reasons for deploying a visibility network are varied and can include network management and optimization, business intelligence/reporting, compliance validation, service assurance, security monitoring, and so on.
FIG. 1 depicts an example visibility network 100 according to an embodiment. As shown, visibility network 100 includes a number of taps 102 that are deployed within a core network 104. Taps 102 are configured to replicate data and control traffic that is exchanged between network elements in core network 104 and forward the replicated traffic to a packet broker 106 (note that, in addition to or in lieu of taps 102, one or more routers or switches in core network 104 can be tasked to replicate and forward data/control traffic to packet broker 106 using their respective SPAN or mirror functions). Packet broker 106 can perform various packet processing functions on the replicated traffic, such as removing protocol headers, filtering/classifying packets based on user-defined filters/rules, and so on. Packet broker 106 can then forward the processed traffic to one or more analytic probes/tools 108, which can carry out various calculations and analyses on the traffic in accordance with the business goals/purposes of visibility network 100.
With respect to traffic filtering, existing packet brokers can accept and apply user-defined filters that are based on parameters explicitly present in the traffic replicated from a core network (referred to herein as “first-order” parameters). For example, assume that core network 104 of FIG. 1 is a mobile network and that the traffic replicated from core network 104 is GTP-C/GTP-U traffic. In this scenario, existing implementations of packet broker 106 can accept/apply user-defined filters based on first-order parameters that explicitly appear in GTP traffic such as IMSI, IMEI, APN, QCI, RAT, ULI, etc.
However, existing packet brokers generally cannot accept or apply user-defined filters based on parameters that may be associated with, but are not explicitly present in, the traffic replicated from the core network (referred to herein as “second-order” parameters). For instance, returning to the GTP example above, existing implementations of packet broker 106 cannot accept/apply user-defined filters based on second-order parameters that do not appear in GTP traffic such as, e.g., characteristics of the end-user device connected to a particular GTP session (CPU type, RAM amount, screen size, device type, etc.), geographic location of the end-user device, and others.
If an operator of a visibility network wishes to analyze replicated traffic based on second-order parameters, it is possible to work around this limitation by configuring the network's packet broker to forward all replicated traffic to the analytic probes/tools. The analytic probes/tools can then store the traffic and perform a post-hoc analysis of the stored data to identify the packets of interest. However, in cases where the volume of traffic generated by the core network is high, this approach will generally require a significant amount of compute and storage resources on the analytic probes/tools in order to store and analyze all of the replicated traffic, which undesirably increases the cost and complexity of the visibility network.